Answer application handler

Applies AI-generated answers to form controls on assignment pages. Covers question types, answer shape checks, DOM writes, synthetic user events, errors, and Chrome vs Firefox differences.

The Answer Application Handler resides in the content script layer of the assignment-solver extension. It communicates with the background script via message passing and interacts directly with the page DOM to apply answers and submit assignments.

graph TB
subgraph "UI Layer"
UI_Solve["UI Solve Controller<br/>(solve.js)"]
UI_Detect["UI Detection Controller<br/>(detection.js)"]
end
subgraph "Background Script"
BG_Answers["Answer Handler<br/>(answers.js)"]
BG_Messages["Message Types<br/>(messages.js)"]
end
subgraph "Content Script"
CS_Index["Content Script Entry<br/>(index.js)"]
CS_Applicator["Answer Applicator<br/>(applicator.js)"]
CS_Logger["Content Logger<br/>(logger.js)"]
end
subgraph "Platform Abstraction"
Platform_Browser["Browser Polyfill<br/>(browser.js)"]
end
UI_Solve --> BG_Messages
UI_Solve --> BG_Answers
BG_Answers --> CS_Index
CS_Index --> CS_Applicator
CS_Applicator --> CS_Logger
BG_Answers --> Platform_Browser

• Answer Applicator: Applies answers to single-choice, multiple-choice, and fill-in-the-blank form elements. It simulates user interactions by triggering click events and input/change events.
• Content Script Entry: Receives messages from the background script, initializes services, and forwards commands to the applicator.
• Answer Handler: Manages content script injection, message routing, and error handling for answer application and submission.
• Message System: Defines standardized message types for communication between UI, background, and content scripts.
• Cross-Browser Compatibility: Uses webextension-polyfill for unified browser APIs and includes Firefox-specific initialization delays.

The handler follows a message-driven architecture:

• UI controllers trigger actions (solve, apply answers, submit).
• Background answer handler checks that the content script is loaded, then forwards messages.
• Content script applies answers to the DOM and triggers submission.

sequenceDiagram
participant UI as "UI Solve Controller"
participant BG as "Answer Handler"
participant CS as "Content Script"
participant APP as "Answer Applicator"
UI->>BG : "APPLY_ANSWERS" with answers[]
BG->>CS : "PING" (ensure loaded)
BG->>CS : "APPLY_ANSWERS" with answers[]
CS->>APP : applyAnswers(answers[])
APP->>APP : applySingleChoice()/applyMultiChoice()/applyFillBlank()
APP-->>CS : success
CS-->>BG : {success : true}
BG-->>UI : {success : true}
UI->>BG : "SUBMIT_ASSIGNMENT" with submitButtonId
BG->>CS : "SUBMIT_ASSIGNMENT"
CS->>APP : submitAssignment(submitButtonId)
APP-->>CS : success
CS-->>BG : {success : true}
BG-->>UI : {success : true}

Answer applicator#

The applicator encapsulates three primary operations. single-choice selection, multi-choice selection, and fill-in-the-blank text input. It validates inputs, performs reliable DOM queries, and simulates realistic user interactions.

• Supported question types:

• Single choice (radio button)

• Multi choice (checkbox)

• Fill in the blank (input/textarea)

• Answer format validation:

• Single choice requires answer_option_id.

• Multi choice accepts a single ID or an array of IDs.

• Fill in the blank requires answer_text and optionally answer_option_id for targeting.

• DOM manipulation techniques:

• Radio buttons: click() followed by change event dispatch.

• Checkboxes: toggle click() and change event dispatch per option.

• Text inputs: set value, dispatch input, change, and keyup events.

• Dynamic element detection:

• Attempts lookup by ID, value attribute, name containing question ID, and partial ID matches.

• For fill blanks, searches across input and textarea elements within question containers.

• User interaction simulation:

• Dispatches synthetic events to trigger change handlers and validation logic.

• Ensures UI reflects selections immediately.

flowchart TD
Start(["applyAnswers(answers[])"]) --> Loop["For each answer"]
Loop --> Type{"question_type"}
Type --> |single_choice| SC["applySingleChoice(answer)"]
Type --> |multi_choice| MC["applyMultiChoice(answer)"]
Type --> |fill_blank| FB["applyFillBlank(answer)"]
Type --> |other| LogUnknown["Log unknown type"]
SC --> SC_Find["Find radio by ID/value/name/partial ID"]
SC_Find --> SC_Click{"Element found?"}
SC_Click --> |Yes| SC_Dispatch["click() + change event"]
SC_Click --> |No| SC_Log["Log not found"]
MC --> MC_Query["Query checkboxes by name/id"]
MC_Query --> MC_Toggle["Toggle checked state per option"]
MC_Toggle --> MC_IDLookup["Direct ID/value/partial ID lookup"]
MC_IDLookup --> MC_Dispatch["click() + change event"]
FB --> FB_Find["Find input/textarea by ID/name/partial ID"]
FB_Find --> FB_Input{"Element found?"}
FB_Input --> |Yes| FB_Set["Set value + dispatch input/change/keyup"]
FB_Input --> |No| FB_Log["Log not found"]
SC_Dispatch --> End(["Done"])
SC_Log --> End
MC_Dispatch --> End
FB_Set --> End
FB_Log --> End
LogUnknown --> End

Content script entry#

The content script initializes logging, creates extractor and applicator instances, and listens for messages from the background script. It supports health checks, page extraction, scrolling, and answer application/submission.

• Message handling:

• PING: responds to health checks.

• GET_PAGE_HTML: extracts page HTML and images.

• GET_PAGE_INFO: quick assignment detection metadata.

• APPLY_ANSWERS: delegates to applicator.

• SUBMIT_ASSIGNMENT: triggers submission with fallback selectors.

• Cross-browser compatibility:

• Uses webextension-polyfill for unified browser APIs.

• Includes Firefox-specific initialization delay in the answer handler.

sequenceDiagram
participant BG as "Background Script"
participant CS as "Content Script"
participant APP as "Answer Applicator"
BG->>CS : {type : "PING"}
CS-->>BG : {pong : true}
BG->>CS : {type : "APPLY_ANSWERS", answers[]}
CS->>APP : applyAnswers(answers[])
APP-->>CS : success
CS-->>BG : {success : true}
BG->>CS : {type : "SUBMIT_ASSIGNMENT", submitButtonId}
CS->>APP : submitAssignment(submitButtonId)
APP-->>CS : success
CS-->>BG : {success : true}

Answer handler (background)#

The background answer handler manages content script lifecycle and message routing. It checks that the content script is loaded, injects if missing, and forwards messages with error handling.

• Content script injection:

• Sends PING to verify readiness.

• Executes content script if missing.

• Applies extended delay for Firefox initialization.

• Error handling:

• Catches injection failures and instructs users to refresh the page.

• Forwards errors from content script responses.

flowchart TD
Start(["handleAnswerMessage"]) --> CheckTab["Resolve tabId (active if missing)"]
CheckTab --> Ping["tabs.sendMessage(PING)"]
Ping --> PingOK{"Responded?"}
PingOK --> |Yes| Forward["Forward message to content script"]
PingOK --> |No| Inject["Execute content script (content.js)"]
Inject --> Delay["Wait for Firefox delay"]
Delay --> Verify["Ping again to verify"]
Verify --> Forward
Forward --> Done(["Send response"])
Inject --> InjectFail{"Injection failed?"}
InjectFail --> |Yes| Error["Send error: refresh page"]
InjectFail --> |No| Forward

Message types and validation#

Standardized message types define the contract between UI, background, and content scripts. The applicator validates answer arrays and individual answer objects before applying.

• Message types:

• PING, GET_PAGE_HTML, GET_PAGE_INFO, APPLY_ANSWERS, SUBMIT_ASSIGNMENT.

• Answer validation:

• applyAnswers checks for array presence and iterates with per-answer error handling.

• Single/multi/fill handlers validate required fields and log missing data.

Cross-Browser compatibility#

The extension targets both Chrome and Firefox using webextension-polyfill. The answer handler includes a deliberate delay for Firefox so the content script initializes before sending messages.

• Browser detection:

• detectBrowser() identifies Firefox vs Chrome.

• isFirefox()/isChrome() helpers for conditional logic.

• Initialization differences:

• Firefox receives a longer wait after content script injection.

The applicator depends on the content script environment and browser APIs. The content script depends on the applicator and logger. The background answer handler depends on tabs and scripting adapters and coordinates with the content script.

graph TB
BG_Handler["Background Answer Handler<br/>(answers.js)"] --> BG_Messages["Message Types<br/>(messages.js)"]
BG_Handler --> CS_Index["Content Script Entry<br/>(index.js)"]
CS_Index --> CS_Applicator["Answer Applicator<br/>(applicator.js)"]
CS_Index --> CS_Logger["Content Logger<br/>(logger.js)"]
BG_Handler --> Platform_Browser["Browser Polyfill<br/>(browser.js)"]
UI_Solve["UI Solve Controller<br/>(solve.js)"] --> BG_Messages
UI_Solve --> BG_Handler

• DOM queries are optimized with targeted selectors and fallbacks to reduce unnecessary traversal.
• Synthetic events are dispatched minimally and only when elements are found.
• Multi-choice processing iterates through discovered checkboxes and toggles only when needed.
• Logging is used to avoid repeated expensive operations and to surface issues early.

Common issues and resolutions:

• Content script not loaded:
• The answer handler attempts injection and verifies with PING. If still failing, instruct users to refresh the page.
• Answers not applied:
• Verify answer arrays are present and properly formatted. Check logs for unknown question types or missing IDs.
• Submission fails:
• Confirm submit button selectors are matched. The applicator tries multiple fallbacks if the explicit ID is unavailable.
• Cross-browser delays:
• Firefox may require additional initialization time. The handler includes a delay to mitigate timing issues.

Validate the answer payload, find the control, simulate input, and surface failures per question instead of failing the whole batch silently.